Certain electronic documents may be animated by including within it software code that alters the appearance and structure of the document over time. As an example, a single HTML document (e.g., a webpage) may include HTML elements, Cascading Style Sheet (CSS) elements, JavaScript code and/or embedded assets such as images, videos, and/or audio content. The HTML and CSS portions of the document form a document structure that determines how the document is displayed or rendered by a web browser or the like. Meanwhile, the JavaScript code may be executed by the web browser to manipulate the HTML and CSS elements as well as their properties and/or attributes, thus altering the structure of the document and the manner in which the document is rendered. By altering the structure of the document over time, JavaScript effectively animates the document.
Some animations or multimedia presentations may include one or more actors (e.g., images or other content to be animated) performing various tasks, movements, or transitions on a stage (e.g., a screen or display). For example, a relatively simple animation may include a transition that hides or shows an object in a computer window. Meanwhile, a more complex animation may include a set of two or more actors (e.g., images of human characters), each actor having a set of elements (e.g., head, arms, body, legs, etc.) that may be displayed in a coordinated or choreographed manner to give the viewer the impression that the actors are moving (e.g., walking, jumping, etc.) across the screen.
Some browsers (e.g., browsers for mobile devices, such as cellular phones or tablet devices, etc.) use graphics processing unit (GPU) acceleration to speed up animations. Often in mobile environments, central processing units (CPUs) and other resources are even more constrained than in a desktop environment. For smoother animations, the browser may take snapshot images of elements that are being animated and send them, as texture bitmaps, to the GPU for faster compositing. Some browsers and/or GPUs and/or other component, however, impose limits (e.g., 1024 pixels in the width and/or height dimension) on the dimensions of the snapshot images that are sent to the GPU. When one of those limits is exceeded, the browser may resort to rendering the display list for that element N times, where N is the number of tiles used to represent the element, thereby creating a bottleneck in the animation. The result of these limitations is that, during an animation that moves the element across the screen, the screen is updated with a distracting, checkerboard-type update as a viewer sees pieces of the old scene and pieces of the new scene at the same time as the display is updated piece by piece.
An example of the above-noted limitations can be seen in FIGS. 1A-1B, 2A-2C, and 3. An example screen size is shown in FIG. 1A as 200×100 pixels and an example maximum size of a GPU texture is shown in FIG. 1B as 200×200 pixels.
A 600×200 pixel actor is shown in FIG. 2A as SCENE-A. One example scenario in which an actor may be larger than the screen is a panning scenario. FIG. 2B illustrates an overlay of the maximum GPU texture size of FIG. 1B on top of the 600×200 pixel actor of FIG. 2A. Note that the actor exceeds the maximum size of the GPU texture. As shown in FIG. 2C, the browser animating the scene tiles the actor to half the maximum size, 100×100 pixels. Thus, the actor is tiled into 12 separate tiles. The actor is completely re-rendered into each of the tiles (at different offsets to show a different part of the actor) meaning that the actor in this example must be rendered 12 separate times. The additional renderings are typically performed in software and become a bottleneck for the animation. The effects of that bottleneck are shown in FIG. 3.
FIG. 3 illustrates a sequence of five images showing a scene transition from a smiley face to the scene SC. The smiley face may be one actor and the image representing the scene may also be an actor. When the actor is initially displayed at the start of the animation, it is displayed in pieces (tiles) as the browser finishes rendering each tile asynchronously. The rendering of each tile and the updating of the screen by the GPU occur independently/asynchronously. So as the GPU continually updates the screen with each step of the animation, the browser sends tiles to the GPU as they finish rendering. The result is an undesired checkerboard update effect on the screen/display (as shown in FIG. 3), because all of the tiles finish rendering at different times.